Skip to content

tests: Fix cdylib-export-c-library-symbols to work with LTO-enabled CFLAGS#156012

Closed
jchecahi wants to merge 1 commit intorust-lang:mainfrom
jchecahi:cdylib-export-c-library-symbols-lto-fix
Closed

tests: Fix cdylib-export-c-library-symbols to work with LTO-enabled CFLAGS#156012
jchecahi wants to merge 1 commit intorust-lang:mainfrom
jchecahi:cdylib-export-c-library-symbols-lto-fix

Conversation

@jchecahi
Copy link
Copy Markdown

@jchecahi jchecahi commented Apr 30, 2026 •
edited by rustbot
Loading

The test fails on systems where default CFLAGS include LTO flags (e.g., -flto=auto -ffat-lto-objects), which is common in RHEL, Fedora, and CentOS distributions:

=== STDERR ===
error: failed to process C static library `foo`: LTO object in C static library is not supported
error: aborting due to 1 previous error

The issue occurs because build_native_static_lib() recompiles the C source using system CFLAGS, which may include LTO. When rustc tries to process this static library with the +export-symbols modifier, it correctly rejects it as LTO objects in C static libraries are not supported (see #150992).

Fix by manually compiling the C code passing -fno-lto to cc() to override system defaults, then using llvm-ar() directly to create the static library. This ensures the test validates the +export-symbols feature rather than LTO compatibility.

@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 30, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Apr 30, 2026

r? @jdonszelmann

rustbot has assigned @jdonszelmann.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 73 candidates
  • Random selection from 20 candidates

@rustbot

This comment has been minimized.

Sign in to view
tests: Fix cdylib-export-c-library-symbols to work with LTO-enabled C…
8d5eac2 
…FLAGS

The test fails on systems where default CFLAGS include LTO flags
(e.g., `-flto=auto -ffat-lto-objects`), which is common in RHEL,
Fedora, and CentOS distributions.

The issue occurs because `build_native_static_lib()` recompiles the
C source using system CFLAGS, which may include LTO. When rustc tries
to process this static library with the `+export-symbols` modifier,
it correctly rejects it as LTO objects in C static libraries are not
supported.

Fix by manually compiling the C code with `-fno-lto` to override
system defaults, then using llvm-ar directly to create the static
library. This ensures the test validates the `+export-symbols`
feature rather than LTO compatibility.
@jchecahi jchecahi force-pushed the cdylib-export-c-library-symbols-lto-fix branch from b503a5d to 8d5eac2 Compare April 30, 2026 17:46
@cezarbbb
Copy link
Copy Markdown
Contributor

cezarbbb commented May 6, 2026

Hi @jchecahi! Thanks for fixing this LTO issue on RHEL/Fedora/CentOS systems, I wasn't aware that system CFLAGS could include LTO flags by default.

I have an open PR #155535 that also modifies this same test file to add Windows/macOS support for the +export-symbols feature. Our PRs will conflict since we're both changing rmake.rs.

I think it makes sense to incorporate your -fno-lto fix into my PR since I'm already rewriting most of that test file anyway. Would you be okay with that? I'll add you as co-author in the commit message. Otherwise if you prefer to keep this separate, I can rebase #155535 on top of yours once it merges.

@jchecahi
Copy link
Copy Markdown
Author

jchecahi commented May 6, 2026

Hi @jchecahi! Thanks for fixing this LTO issue on RHEL/Fedora/CentOS systems, I wasn't aware that system CFLAGS could include LTO flags by default.

I have an open PR #155535 that also modifies this same test file to add Windows/macOS support for the +export-symbols feature. Our PRs will conflict since we're both changing rmake.rs.

I think it makes sense to incorporate your -fno-lto fix into my PR since I'm already rewriting most of that test file anyway. Would you be okay with that? I'll add you as co-author in the commit message. Otherwise if you prefer to keep this separate, I can rebase #155535 on top of yours once it merges.

Hi @cezarbbb! Absolutely, I have no problem incorporating this PR into #155535 if that makes your life any easier :)

@cezarbbb cezarbbb mentioned this pull request May 6, 2026
Open
@cezarbbb
Copy link
Copy Markdown
Contributor

cezarbbb commented May 6, 2026

I have updated PR #155535, please check :>

@jchecahi
Copy link
Copy Markdown
Author

jchecahi commented May 6, 2026

@cezarbbb thank you! Should I close this PR already?

@cezarbbb
Copy link
Copy Markdown
Contributor

cezarbbb commented May 6, 2026

I think we should wait for the assignee's reply first?

@jdonszelmann
Copy link
Copy Markdown
Contributor

jdonszelmann commented May 8, 2026

It looks like this can be part of that other PR, I'm all fine with that. I've gotten quite busy so I'm not sure I can spend much more time on this. If the consensus is to close, sounds good!

@cezarbbb
Copy link
Copy Markdown
Contributor

cezarbbb commented May 8, 2026

Thank you so much! I will follow up on this issue in that PR :>

@jchecahi
Copy link
Copy Markdown
Author

jchecahi commented May 8, 2026

Well it seems we have an agreement here, so I'm closing this PR in favor of the other one. Thank you both for your time!

@jchecahi jchecahi closed this May 8, 2026
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@jdonszelmann jdonszelmann

Labels

A-run-make Area: port run-make Makefiles to rmake.rs T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@jchecahi @rustbot @cezarbbb @jdonszelmann